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DETAILED ACTION 

1. This communication is in response to Amendment filed 08/19/04, claims 25, 28, 32-33, 38, 40- 
41, 51-54, have been amended, claims 1-24, 35 and 56 have been canceled, and claims 58-62 have been 
added. Claims 25-34, 36-55, and 57-62 have been examined as hereby set forth. 

2. Quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections 
xmder this section made in this Office action may be found in previous office action. 

3. Claims 25-34, 36-55, and 57-62 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Humpleman et. al. U.S. Patent N. 6,546,419 Bl (referred to as Humpleman hereafter). 

Regarding claim 25, Himipleman teaches substantial features of the invention as claimed, teaches a 
method comprising: 

creating a definition of a controlled device using an XML-based language (Humpleman: created 
XML based XCE definition of CE devices see col 12/lines 35-54, said definition describes device, col 
12/lines 46-54, said definition for controlling said controlled device see col 14/lines 6-19); 

storing the definition on a computer-readable medium (Humpleman: each device has definition 
stored therein see col 15/lines 39-45, 55-60, database termed XCE definition, i.e. computer readable 
medium see col 12/lines 35-54, or stored in a library universally accessible see col 20/lines 31-45, stored 
at searchable library, i.e. computer readable medium see col 16/lines 38-50), 

wherein the definition includes a service control protocol definition describing a protocol based 
message exchange (Humpleman describes a document definition INTERFACE-A.XML used to 
determine how to communicate with a device for service by defining the message format for the service, 
col 13/line 1-8, and describing the services available, col 13/46-56, an XML protocol conununication 
stack at the API level on each device is used for sending (68) and receiving (70) messages over the 
network, the XCE definition and the XML definition of a method call, namely called the document type 
definition CALL.DTD and document type definition .INTERFACE.DTD. are used to create the 
communication stack (68 & 70 respectively) col 15/lines 8-27, the document definition CALL.DTD 
which describes interaction with the controlled device on the network (col 13/lines 9-17), including a rule 
set for generating method call or function call message (i.e. protocol), such as XML Remote Procedure 
Call (RPC) or XMLRPC messages, col 13/lines 46-56). 
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Regarding claim 26, the storing comprises storing the definition on a computer-readable medium resident 
at the controlled device (Humpleman: each device includes a local definition software see col 15/line 39- 
49, i.e. "stored on a computer-readable medium"). 

Regarding claim 27, storing the definition on a computer-readable medium located remotely firom the 
controlled device (Humpleman: stored on another device. Hub or library searchable over the Internet see 
col 16/lines 39-58, or distributed, i.e. remotely from device see col 17/lines 20-25). 

Regarding claim 28, generating a control message from the controlled device, the controlled message 
being generated in accordance with the definition (Humpleman: create command by examining the 
document definition retrieved from controlled device see col 14/lines 20-28, 35-38, generate commands 
using controlled device interface, i.e. XML document definition see col 18/lines 3-17, allows the 
generation of commands as specified by the definition for controlling the device see col 21/lines 46-col 
22/lines 17). 

Regarding claim 29, wherein the creating comprises: 

creating a device portion of the definition that defines attributes of the controlled device 
(Humpleman: XML based definition includes information that defines capabilities and attributes of the 
device, i.e. "device portion" see col 21/lines 47-62); and 

creating a service portion of the definition that defines one or more services exposed by the 
device (Humpleman: definition describes the object/methods supported by the service provided by the 
device, i.e. "service portion" see col 12/lines 45-54, definition provides fiill description of the services 
provided by the device see col 24/lines 40-42). 

Regarding claim 30, storing the device portion on a first computer-readable medium resident at the 
controlled device (Humpleman: each device has definition stored locally therein see col 15/lines 44-49, 
controlled and controlling device store therein a XML base definition see col 19/lines 51-58, definition 
includes a device portion, e.g. defines the method of the device see col 12/lines 35-45 or device 
capabilities see col 21/lines 47-62); and 

storing the service portion on a second computer-readable medium located remotely from the 
controlled device, but accessible over a network (Humpleman: each device has definition stored 
accessible over the network at a hbrary 106 see col 20Aines 31-45, searchable library or over the Internet 
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col 16/lines 38-58, retrievable over the network see col 15/lines 31-38, service portion included see co 
13/lines 46-56). 

Regarding claim 31, further comprising making both the device portion and the service portion available 
at runtime over a network (Humpleman: interface definition including device description see col 21/lines 
47-62 and service description see col 13/lins 46-56 where said definition is available at runtime see col 
19/lines 51-58). 

Regarding claim 32, storing a definition of the computing device, the definition being written is using an 
XML-based language (Humpleman: XML based interface defmition col 12/lines 35-54, storing locally at 
each device see col 15/lines 44-49, stored locally or remotely retrieved see col 15/lines 63-col 16/line 8); 

wherein the definition defines (set of instruction) protocol bases messages that describe services 
(Humpleman: INTERFACE.XML having definitions XCE & rNTERFACE.DTD. which describe the 
services provided by the device, col 12/lines 46-54 and the message for conununicating with said 
services, col 13/lines 1-8, 46-56, the XML based definitions including XML protocol based message call 
definitions for sending and receiving messages col 15, lines 8-27), and 

making the definition available to other computing devices on the network (Humpleman: available 
for other devices see col 15/lines 33-38, accessible library see col 20/lines 31-45). 

Regarding claim 33, a first set of XML-based code strings that define attributes of the device 
(Humpleman: XML based definition includes information that defmes capabilities and attributes see co 
21/lines 46-62); and 

a second set of XML-based code string that define the service(s) exposed by the device 
(Humpleman: definition describes the object/methods supported by the service applications residing on 
the device see col 12/lines 45-54), 

wherein the second set includes data to create messages (called "service specific data messages) 
(Humpleman: CALL.DTD which describes the interaction (message exchange), col 13/lines 9-17, the 
services available, wherein the CALL.DTD definition includes a rule set for generating method call or 
fimction call message (i.e. protocol), such as XML Remote Procedure Call (RFC) or XMLRPC messages 
col 13/lines 46-56). 

Regarding claim 34, wherein the first set of XML-based code strings contain a reference to the second set 
of XML-based code strings (Humpleman: reference to application services col 15Aines 2-8). 
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Regarding claim 35, wherein the first set of XML-based code strings contain a reference to the second set 
of XML-based code strings (Humpleman: URL reference see col 14/lines 63-col 15/line 8). 

Regarding claim 36, wherein the first set of XML-based code strings is stored on a first computer 
readable medium and the second set of XML-based code strings are stored on a second computer readable 
medium separate from the first computer-readable medium (Humpleman: subset of definition of the 
services are used by the controlling device to control the controlled device see col 12/lines 46-54, parts of 
the controlled device definition interface are request from the library see col 17/lines 56-col 8/line 3). 

Regarding claim 37, wherein is the second set of XML-based code strings that define the services 
exposed by the device comprises IJRL(s) to a location(s) that host description(s) of the service(s) 
(Humpleman: description interface comprises URLs see col 14/lines 63-col 15/line 8, URL to portion of 
the description definition see col 21 /lines 9-22, description definition includes services descriptions see 
col 13Aines 46-56). 

Regarding claim 38, a device description written in an XML-based language to describe a controlled 
device (Humpleman: document definition XML based of the device see col 12/lines 35-54); and 

a service description written in an XML-based language to describe a service supported by the 
controlled device (Humpleman: document definition describes the object and methods supported by the 
service that the device provides see col 12/lines 46-54); 

the service description defmition describes how to access a service at the controlled device 
(Humpleman: the INTERFACE-A.XML is used to determine how to communicate with a device for 
service by defining the message format for the service, col 13/line 1-8, and describing the services 
available col 13/46-56) 

Regarding claim 39, wherein the device description is stored at a first location and the service description 
is stored at a second location remote firom the first location, but accessible via a network (Humpleman: 
library accessible over the network see col 16/lines 38-58, device service description stored on controlled 
device see col 15/lines 39-49, part of the description definition may be available/accessible at the library 
see col 17/lines 56-col 8/line 3), 

Regarding claim 40, wherein the device description contains a reference to the service description 
(Humpleman: hierarchical device interfece definition including device description i.e. device attributes 
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and capabilities and farther to control interface which contain references to device interface services such 
as video services sink for a specified control interface see col 21/lines 47-col 22/lines 39). 

Regarding claim 41, wherein the device description contains at least one other device description nested 
therein (Humpleman: description definition is a hierarchical device interface definition including control 
interface description definition that farther includes, i.e. "nested" description definitions see col 21/lines 
47-col 23/line 3). 

Regarding claim 42, a description, written in an XML-based language, that describes how to is remotely 
operate the computing device (Humpleman: XML based document defmition describes the object and 
method of the device col 12/lines 35-54, said defmition is used to remotely control, i.e. send command to 
the device see col 14/lines 20-42); and 

description means, responsive to a description request received by the computing device on a 
network, for sending a description message based on the description that defines interaction via data 
messaging with the computing device over the network (Humpleman: create commands for sending to 
controlled device over the network see col 14/lines 35-62, sending control and command data to 
controlled device based on description definition e.g. capabilities see col 27/lines 63-col 28/line 12). 

Regarding claim 43, this claim is substantially the same as method claim 29 where description includes a 
"device/service portion" of the definition associated with the controlled device, same rationale of 
rejection is apphcable to this "device/service description" associated with the computing device. 

Regarding claim 44, wherein the device description and the service description are located remotely from 
one another and separated by a network (Humpleman: part of the definition interface may be retrieved 
from the library see col 17/lines 56-col 18/line 3 which is located over the Internet see col 16/lines 38-58 
or distributed see col 17/lines 15-25, service (e.g. fanctions) description fields that define services 
exposed by the controlled device located remotely from the controlled device but accessible over the 
network see col 20/hnes 49-64). 

Regarding claim 45, this claim is substantially the same as method claim 31 discussed above, same 
rationale of rejection is apphcable. 
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Regarding claim 46, wherein the description comprises multiple descriptions that describe how to 
remotely operating multiple computing devices logically contained within the computing device 
(Humpleman: remotely controlling controlled devices using description software stored within see col 
15/lines 34-49, description provides the capabilities and commands for communicating/controlling 
controlled device see col 14/lines 6-60). 

Regarding claim 47, wherein the description is a first description written in an XML-based language that 
describes how to remotely operate another computing device, the second description being nested within 
the first description (Humpleman: definition including the capabilities of the controlled device used to 
remotely operate another device see col 14Aines 6-60, hierarchical structure definition, e.g. where service 
definition includes sub-descriptions, i.e. "nested" description e.g. utilities for controlling device specific 
interfaces and specific capabihties of the device see col 21/lines 47-col 23/lines 3). 

Regarding claim 48, a computing device comprising: 

a memory (Humpleman: each device has definition stored locally therein see col 15/lines 44-49, 
blocks 52 and 58 of Fig. 15, data base, i.e. storage or memory device definition device XML based see 
col 12/lines 35-54); 

self-describing data stored in the memory and written in an XML-based language the 
self-describing data describing how to operate the computing device (Humpleman: data base stored object 
and method describe the methods and object of the device, i.e. "self describing data" see col 12/lines 35- 
54); and 

a processor coupled to the memory to submit the self-describing data to remote entity on a 
network (Humpleman: data retrievable, i.e. submitted by another device over the network see col 14/line 
62-col 15/line 6, i.e. corresponding hardware resource for performing this retrieval, i.e. processor coupled 
to memory, and fiirther transferring the definition document "self-describing data" between controlled 
device and controller device over the network see col 14/lines 20-34). 

Regarding claim 49, this claim regarding the definition data "self-describing data" comprising a 
first/second data is substantially the same as "device portion" and "service portion" discussed on the 
method claim 29, the computer-readable media claim 33 having a "first/second set of XML-based code 
strings" discussed on claim 33, and data structure claim 38 having a "device/description" schema, same 
rationale of rejection is applicable. 
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Regarding claim 50, wherein the self-describing data comprises device data to describe attributes of the 
computing a device (Humpleman: device attributes see col 21/lines 46-62) and a universal resource 
locator(s) to a service(s) exposed by the computing device (Humpleman: URI see col 15/lines 2-8). 
Regarding claim 51, multiple controlled devices configured to dynamically self-bootstrap onto the 
network (Humpleman: devices self configure at runtime with native functionalities, i.e. "self bootstrap" 
see col 16/lines 24-38), 

individual controlled devices comprising a device description to describe attributes of the 
computing device and a service description to describe a service(s) exposed by the computing device 
(Humpleman: each device having definition stored therein for being controlled see col 15/lines 39-49, 
definition including description of the attributed of the controlled device see col 21/lines 47-62, and a 
description of the services or capabilities provided by the device see col 14/line 14-10 and col 13/lines 46- 
56, description of the object, methods and parameters supported see col 15/lines 39-49); 

the device and service descriptions being written in an XML-based language (Humpleman: 
definition is an XML based document see col 12/lines 35-54); and 

defining a messaging protocol (Humpleman: an XML messaging communication protocol for 
sending/receiving messages over the network col 15/lines 8-27, including a call definition includes a rule 
set for generating method call or fimction call message, e.g. XML Remote Procedure Call (RPC) or 
XMLRPC messages col 13/lines 46-56); 

one or more user control points to initiate communication with the controlled devices over the 
network (Humpleman: definition describes the messages to be used to communicate with controlled 
device see col 13/lines 1-6, using a browser, i.e. control point, see col 11/line 61-col 12/line 5, definition 
used to communicate or send control commands to said device see col 14/hnes 6-10, 20-27, 38-42, 55- 
60). 

Regarding claim 52, wherein the device description and the service description for an associated 
controlled device are both a stored on the associated controlled device (Humpleman: definition is resident 
at controlled device see col 15/line 39-49, definition include attributes of the device see col 21/lines 46-62 
and the service the devices supports see col 12/lines 46-54). 

Regarding claim 53, this claim comprises the architecture comprising limitation(s) substantially the same 
as those discussed on claim 39, same rationale of rejection is applicable. 
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Regarding claim 54, this claim includes the apparatus comprising the means for performing the storing 
and making functions discussed on claim 32, same rationale of rejection is applicable. 

Regarding claim 55, wherein the storing means stores multiple definitions of multiple controlled devices 
(Humpleman: central library see col 16/lines 62-col 17/line 1, or distributes where multiple devices are 
registered on each library col 17/lines 15-29). 

Regarding claim 56, this claim includes the apparatus comprising the description definition comprising a 
first/second set of strings discussed on claim 33, same rationale of rejection is applicable. 

Regarding claim 57, wherein the definition contains multiple device descriptions each describing a 
different set of attributes of the controlled device (Humpleman: each device (controller or controlled) 
contains an interface definition see col 15/lines 39-49, device interface definition includes multiple device 
description fields each describing a different set of capabilities, type, communication and control 
interfaces, i.e. attributes see col 2 I/lines 47-col 22/line 35). 

Regarding claims 58-60, API interface methods and queries, col 14/lines 20-34, notifications col 17/lines 
15-29), service control protocol definition is XML based, col 13/lines 3 1-35. 

Regarding claim 61-62, service description protocol comprises access description (called "service access 
protocol description") (col 10/lines 50-63, col 12/lines 11-24, and col 13/lines 31-45), automatically 
configurable (col 10/lines 50-63). 

Response to argument 

4. It is argued that prior art does not teach claim limitations as added, in substance, where the 
definition includes a protocol based messaging exchange (called "service control protocol definition"), 
that define the (interface) services through which the messages are communicated, the definition 
including data to create the messages and how to access the services supported by the device through the 
messages. 

In response to the above-mentioned argument, the claimed term service control protocol 
definition has been interpreted in Ught of the specification broadly speaking a defining or describing a 
protocol based message exchange, as described by the specs p. 14, lines 11 17 , p. 43, lines 14-18). 



Application/Control Number: 09/81 U36 (ZINTEL et. al.) 
Art Unit: 2142 



Page 9 



Humpleman teaches an application interface language (XML commands) is utilized to allow 
different devices to control other devices ("device-to-device control"), or where servers control devices 
over the network ("device-to-server), including control for a desired service col 10/lines 50-63, such 
interfaces (API) extensions use an XML-based interface, to provide overall interoperability col 12/lines 
1 1-24, and provide for communication between various devices on the network using XML, wherein code 
for Service generates method calls to an API, for inter-device communication, wherein the XML method 
calls (messages) are sent to a service over the network, the extensions are implemented using interface 
blocks. Fig. 15, col I3/lines 31-45. 

A first device wishing to control the second device in the network, would use the INTERFACE- 
A.XML document definition to query the capabilities and API interface methods of the second device A, 
allowing the first device to control the second device utilizing XML remote procedure calls (XMLRPC), 
(col 14/lines 20-34) 

The definitions of API extensions for the services of the network device (e.g. Service A) provides 
a (block 52) comprehensive definition of CE objects and their respective methods to describe CE devices 
in a XML (i.e. termed XCE definition), (block 54) a API definition in XML for all devices 14, 
designated as an interface data type definition Interface.DTD. col 12/lines 35-45, (block 60) provides a 
language definition for making XML form method (command) calls to remote API services or devices 
such as the API for Service A (i.e. a document type definition). Method Request CALL. DTD, which 
describes interaction with objects on the network (col 13/9-17), document definitions 
INTERFACE.DTD. & CALL.DTD are used to describe the services available (namely called 
INTERFACE. XML), the CALL.DTD definition includes a rule set for generating method call or 
function call message, e.g. as XML Remote Procedure Call (RPC), i.e. a protocol, or XMLRPC 
messages, the definition describes an output interface of a controller service, col 13/lines 46-56. 

An INTERFACE-A.XML is formed from a subset of the XCE definition for Service, and the 
interface data type INTERFACE.DTD to create an XML form document. The document INTERFACE- 
A.XML describes the objects and methods supported by the Service A according to the document type 
definition INTERFACE.DTD for Service A, col 12/lines 46-54. The INTERFACE-AXML is used to 
determine how to communicate with a device for service by defining the message format for the service, 
col 13/hne 1-8, and describes the services available col 13Aines 46-56, 

An XML protocol communication stack at the API level on each device is used for sending (68) 
and receiving (70) messages over the network. The XCE definition and the XML definition of a method 
call, namely called the document type definition CALL.DTD and document type definition 
INTERFACE.DTD are used to create the communication stack (68 & 70 respectively) col 15/lines 8-27. 
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5. 



Applicant's arguments filed 8/19/04 have been fiiUy considered but not found persuasive. 



6. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set 
forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE MONTHS from 
the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing 
date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH 
shortened statutory period, then the shortened statutory period will expire on the date the advisory action 
is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated fi^om the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later than SIX 
MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earher communications from the examiner should 
be directed to Prieto, B. whose telephone number is (703) 305-0750. The Examiner can normally be 
reached on Monday-Friday from 6:00 to 3:30 p.m. If attempts to reach the examiner by telephone are 
unsuccessfiil, the Examiner's Supervisor, Jack B. Harvey can be reached on (703) 305-9705. The central 
fax phone number for the organization where this application or proceeding is assigned is (703) 872-9306. 
Any inquiry of a general nature or relating to the status of this application or proceeding should be 
directed to the receptionist whose telephone number is (703) 305-3800/4700. 

Any response to this action should be mailed to: 



Washington, D C. 20231 

or faxed to the Central Fax Office: 

(703) 872-9306, for Official commimications and entry; 

Or Telephone: 

(703) 306-5631 for TC 2100 Customer Service Office. 

Hand-delivered responses should be brought to Crystal Park II, 2121 Crystal Drive, Arlington 
VA, Fourth Floor (Receptionist), fiirther ensuring that a receipt is provided stamped "TC 2100". 
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